home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
PsL Monthly 1993 October
/
PSL Monthly Shareware CD-ROM (Public Software Library) (October 1993).iso
/
dos
/
prgmming
/
progrmmr.let
< prev
next >
Wrap
Text File
|
1993-08-30
|
10KB
|
230 lines
PsL Programmers Newsletter
Copyright October 1993 PsL
Contents:
========
1. MEI Is Now Marketing Low-Cost Shareware CDs
2. "Extras" You Should Be Adding to Your Files
- CD-ROM Acceptable File Names
- Screen Shots
- File Viewer
- Make Your Installation Generic
- Don't Leave Out Windows' Files
- Tell us your preferred ZIP file name
= Commentary: Anti-Version-Number-In-ZIP-Name
3. Why Did You Write that Program?
Text:
====
1. MEI Is Now Marketing Low-Cost Shareware CDs:
MEI, the company that sends out about a jillion catalogs a month selling
low-cost disks and other computer supplies featured shareware CDs on the cover
of their latest catalog.
On the inside, front cover was a remarkably good shareware explanation.
As Rob Rosenberg put in on the ASPFORUM on CompuServe: "This may be a sign
that the CD-ROM revolution is finally on its way."
PsL is beginning a national advertising campaign which will let people get a
CD-ROM drive and three months of the PsL Monthly CD for a total (including the
drive) of as little as $66 per month. At that price, who can afford NOT to
have a CD-ROM drive?
2. "Extras" You Should Be Adding to Your Files:
Do you want to reach the broadest possible market with the greatest impact?
If so, there are some easy, no-cost steps you can take to increase the chances
that your program will be distributed by as many sources as possible.
- CD-ROM Acceptable File Names:
CD-ROMs only allow file names with letters, numbers, and the underscore sign
("_") in them - no dashes or other non-alphanumeric characters.
- Screen Shots:
A reader (of a shareware catalog) can tell more about a program from a single
screen shot than from a two-paragraph write-up. It is always time-consuming,
often difficult, and sometimes impossible to get screen shots.
If you have a text-based application, such as a database program, bring up a
good screen with data on it, capture it, and save it as a PCX file, preferably
in color.
I use Paint Shop Pro in Windows to do screen captures. It's the easiest way to
capture a DOS-based text screen in graphic format.
- File Viewer:
Put VIEW.COM from the PsL CD-ROM on your disks. This is a freeware file viewer
by David Dibble. It takes less than 1k of disk space.
Then make a batch file to display all your DOCs, READ.MEs, etc., in the order
you prefer.
- Make Your Installation Generic:
Don't assume that people will be installing your program from a floppy drive
A: or B:. If someone has downloaded your program in ZIP format or gotten it
off a CD-ROM, they will un-ZIP the files to their hard disk.
Ideally, no further "installation" should be required once the files are in a
directory on the hard disk. However, some programmers combine the copying of
files to the hard disk with the system set up (moving data files to specific
subdirectories and selecting screen colors and other system configuration
options).
So in order to select screen colors, the user has to run the INSTALL and let
it copy the files to a *different* directory. At worst, the user may have to
copy the files to a floppy just so the INSTALL can copy them back to the hard
disk!
The configuration functions should be done from a configuration program or
from a menu option in the main program, and the install program should just do
the copying to the hard disk.
Here's something even worse than the "at worst", above: at PsL, we get some
multi-disk programs which can only be installed from individual floppies. So
not only must the user copy the files to *a* floppy, he must copy them to
multiple 360k floppies. Then he/she may have to use DOS's LABEL command to
give the floppies specific labels which the installation is looking for.
Talk about discouraging users...
- Don't Leave Out Windows' Files:
We tested the installation of a Windows app and it worked fine. The first user
to try it couldn't get it to install. Turned out that the installation
required a bunch of files which we (and the programmer, obviously) already
had, but which the user did not. (Actually, they were on the disk, but in
compressed format, which Windows could not use.)
We spent an hour on the phone with the customer trying to work around it, but
ended up sending him disks with the program already installed on them. The
customer called back again - CMDIALOG.VBX was missing. That was one file we
could not tell from the PACKING.LST was required, so we were out another disk
and postage.
Moral: test your Windows apps on a virgin machine before distributing them to
make sure you are including all the files that are needed. Alternatively, if
you have a large hard drive or a Bernoulli drive, install a virgin copy of
Windows on it, then for testing, change your PATH to that copy and run under
it.
One exception to this is VBRUN?00.DLL. If you bloat up your archive by
including the huge VB runtime modules, you greatly reduce the number of people
willing to download the program from BBSs. Most people already have the
runtimes and for those who don't, most vendors and BBSs make them available
separately.
This raises the issue of VB programmers using SETUP.EXE to install their
programs. This may look nice, but it is really a pain in the anatomy.
In the first place, it forces you to include the VBRUN module. For another, it
forces some to go through an installation just to look at the program. The
only benefit seems to be that it lets you automatically create a program group
in PM for your app, which most users already know how to do (if they are using
shareware).
Using SETUP.EXE is not a bad idea for your registered versions, but for the
shareware versions, stick with just archiving the files.
- Tell us your preferred ZIP file name:
Some programmers send us their software on disk(s) unarchived, but upload to
BBSs in ZIP format. CD-ROM publishers have to make up an archive name which
may not match the one you used, which tends to make sysops unhappy.
Anti-Version-Number-In-ZIP-Name Pitch:
Are version numbers in archive names really necessary or desirable?
With FILES.BBS files and FILE_ID.DIZ files to tell callers the version number,
isn't it redundant to put the version number in the file name?
If you do NOT put the version number in the archive name (and assuming you
use the same archive name each time), then you can be assured that old copies
of your program will be replaced by the new one; otherwise, there are sure to
be multiple (outdated) versions of your program(s) floating around.
Take a look at one of these CDs with "20,000 different programs" on them.
About 10,000 of them are the same programs with different archive names.
A sysop called PsL this month to say that he already had "99%" of the software
on our CD - or at least that is what his system told him when he tried to
upload software from our CD to his multi-gig hard disk.
What was really happening was that the programs without version numbers in the
names were trying to write over old versions with the same names. In other
words, the sysop was being forced to replace old versions with new ones or to
not add the new program at all. The reverse implication is that all the
programs with version numbers in the names made it on ok, LEAVING THE OLD
VERSIONS intact on his system.
I've been told that using the same ZIP file name each time causes a problem
for sysops because the author cannot upload a new file with the same name.
Isn't there some way around this? Couldn't their be a "new uploads" section
where a new file with the same name would not overwrite an old one.
3. Why Did You Write that Program?
Look at the Quick Looks in this month's PsL News and you'll see program after
program of stuff that has already been done to death - and often done better.
I suspect the reason for this is because the programmers simply are unaware
that similar programs already existed. There's an easy solution to that
problem - check out PsL's Reviews